Pre-computing streaming media payload method and apparatus

ABSTRACT

A method for pre-computing a streaming media payload in a server includes receiving a data file from a streaming media server, determining a plurality of data packets from the data file, dividing the plurality of data packets into a plurality of sets of data packets, forming a plurality of data objects, each data object comprising a set of data packets from the plurality of sets of data packets, and storing the plurality of data objects in a server memory, wherein each data object is individually accessible from the server memory.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 09/981,667, filed on Oct. 16, 2001, which issued as U.S. Pat.No. 6,742,082 on May 25, 2004, and which claims priority to ProvisionalU.S. patent application No. 60/297,945, filed on Jun. 12, 2001,entitled, “Pre-Computing Streaming Media Payload Method & Apparatus”,both of which are incorporated herein by reference for all purposes.Co-pending U.S. patent application, Ser. No. 09/981.668, which isentitled. “Caching Media Data Using Content-Sensitive Identifiers,”filed on Oct. 16,2001, and issued on Nov. 2, 2004 as U.S. Pat. No.6,813,690 is also incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

The present invention relates to data caching. More particularly, thepresent invention relates to apparatus for pre-computing streaming mediadata and to methods of operation of streaming data media caches.

Typical file caching methods include a cache receiving a file from afile server, and storing the entire file. Later, when a client desiresthe file, instead of serving the file from the file server, the file isserved from the cache. Because the cache is typically a server that iscloser to the client or has higher bandwidth than the file server, thefile is served to the client quickly from the cache.

It has been discovered by the inventors, that attempting to applytypical file caching methods to files that include streaming media data,raises many new problems. For instance, serving a streaming media datafile from a cache requires much more processing by the cache than withclassical file transfers over the web. For example, during normalplayback, the cache may need to perform a lot of processing such aspacket modification, resequencing, and retiming. As another example, thecache may be called upon to perform random access within the streamingmedia data file as a result of a client “rewind” or “fast forward”operation. Because, classical caching is typically file-based, such arandom access would involve moving within a very large data file.

Another drawback is that since streaming media data files are verylarge, a huge penalty is incurred if the streaming media data file isdeleted. Typically if a file cache determines that it needs more diskspace for new files, it will first delete older files, regardless of thesize. As an example, if an older file is a streaming media data filethat stores an hour-long program, the entire hour-long program isdeleted even if the cache only needs to free up the equivalent of 1minute of space.

Another drawback is that many different streaming media formats exist,each with its own specific streaming requirements. This is in contrastto classical file transfer over the web, where the files are essentiallyopaque to the cache and for streaming data to clients, the cache doesnot need to process the actual contents of the file beyond storage andretrieval.

Thus what is required are improved methods and apparatus for storing andserving streaming media within a cache. Further, what is required aremethods and apparatus for providing such solutions in economical ways.

BRIEF SUMMARY OF THE INVENTION

The present invention relates to streaming media caches and methods ofoperation. More particularly, the present invention relates to systemsfor pre-computation of streaming media payloads in a cache memory.Storing a streaming media clip in the efficient manner described belowallows for flushing from a streaming media cache, portions of astreaming media clip that are not often requested, while maintainingportions of the streaming media clip that are often requested.

In the present disclosure “Streaming media” data generally refers tomedia intended to be transported at a select (often, subscribed) bitrate, and with a desired timeliness. The streaming media is adapted forplayback in a desired order without regard to the order the streamingmedia data are received by a client system. Streaming media generallyconforms to a real-time delivery protocol, such as, e.g., RTSP, RTP, orthe like. The media (media clip) represented in the streaming media datamay include static images, video data, audio data, executable files,presentation data, applet data, data files, and the like.

The data that is cached in a streaming media cache may be an entirestreaming media clip, portions of a streaming media clip, or the like.In the case where there is a streaming media cache hit, the portion ofthe streaming media stored in the streaming media cache is served to aclient. In the case of a streaming media cache miss, the missing portionof a streaming media clip may be retrieved from a media server, insteadof an entire streaming media clip. The missing portion of the streamingmedia clip that is retrieved from an upstream or origin server is thenstored and then served to a client. Storing a streaming media clip inthe efficient method described below allows the streaming media cache tomaintain portions of a streaming media clip that are often requested,and to flush portions of the streaming media clip that are not oftenrequested.

According to one aspect of the invention, a method for storing streamingmedia data in a cache memory is disclosed. One technique includesreceiving a data file from a streaming media server, determining aplurality of payload data packets from the data file to be streamed to aclient system, and determining header data from the data file.Additional methods may include storing a portion of the header data in asession data object in the cache memory, and storing the plurality ofpayload data packets in a plurality of data objects in the cache memory,wherein each data object of the first plurality of data objects isdirectly addressable in the cache memory via an associated objecthandle, and wherein each data object of the first plurality of dataobjects stores a set of payload data packets.

According to another aspect of the invention, a cache memory including aprocessor configured to store streaming media data are disclosed. Thecache memory may include code that directs the processor to receive adata file from a streaming media server, the data file including encodedmedia data, code that directs the processor to determine header datafrom the data file, and code that directs the processor to pre-compute aplurality of payload packets from the encoded media data. In oneembodiment, the cache memory may also include a session data filestoring a portion of the header data, wherein the header data areselected from the group: encoding scheme, duration, and a plurality ofdata objects storing the plurality of payload packets, wherein each dataobject of first plurality of data objects is directly addressable in thecache memory via an associated object handle, and wherein each dataobject of the plurality of data objects stores a set of payload packetsfrom the plurality of payload packets.

According to another aspect of the invention, a computer program productfor a computer system including a processor is described. Included in atangible memory are executable code that directs the processor toreceive a data file from a streaming media server, the data fileincluding encoded media data, executable code that directs the processorto determine header data from the data file, and executable code thatdirects the processor to pre-compute a plurality of payload packets fromthe encoded media data. Additionally, executable code that directs theprocessor to store the header data in a session data object in the cachememory, and executable code that directs the processor to store theplurality of payload packets in a plurality of data objects in the cachememory, wherein each data object of the plurality of data objects isdirectly addressable by the processor in the cache memory via anassociated object handle, and wherein each data object of the pluralityof data objects stores a set of payload packets are included. Thetangible memory may include a hard disk drive, a CD-ROM, removablemedia, and the like.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A–C illustrate overview diagrams according to embodiments of thepresent invention;

FIG. 2 is a simplified block diagram of a computer system according toan embodiment of the present invention;

FIG. 3 illustrates a software hierarchy according to embodiments of thepresent invention;

FIGS. 4A–D illustrate a data format hierarchy according to an embodimentof the present invention;

FIG. 5 illustrates a block diagram of a flow chart according to anembodiment of the present invention;

FIG. 6 illustrates a block diagram of a flowchart according to anembodiment of the present invention; and

FIG. 7 illustrates a block diagram of a flowchart according to anembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1A illustrates a overview diagram according to an embodiment of thepresent invention. In particular, FIG. 1A includes a client system 10, astreaming media cache (server) 20, media data server 30 (streamingserver), and a router 40. The elements of FIG. 1A are coupled asdisclosed over computer networks such as a local area network, wide areanetworks (Internet), wireless networks or the like.

In one embodiment, client system 10 initially makes a request for astream of streaming media. The media (media clip) may include staticimages, video data, audio data, executable files, and the like. Thisrequest may take the form of a user clicking upon a URL on a web page,or the like. In this embodiment, this request is intercepted by router40. Router 40 may be embodied as a layer 4 or layer 7 switch, a WebCache Coordination Protocol (WCCP) router, or any other conventionalswitch or router. In such embodiments, router 40 would be configured torecognize when a request is made by client system 10 for a stream ofstreaming media.

If such a request is determined by router 40, that request is redirectedto streaming media cache 20, and not media data server 30. Oncestreaming media cache 20 receives the request, it makes a determinationwhether the stream (the entire media clip) or the requested portion ofthe stream (the request portion of the media clip) has already beencached. If the data has been previously stored, streaming media cache 20provides the streaming media to client system 10.

In the present embodiment, if the data (requested portion of a stream)has not previously been stored in streaming media cache 20, streamingmedia cache 20 sends a request to media server 30 for a stream of dataincluding the requested portion of a stream. As the requested portion ofthe stream of data are delivered to streaming media cache 20, it isforwarded to client system 10, and the portion of the stream of data arestored.

For this embodiment, the streaming media traffic is received by mediacache 20 from specific ports. In specific embodiments, for RealNetworksRealSystem streaming media, media cache 20 receives streaming media viaTCP on port 554; for QuickTime (RTSP) streaming media, media cache 20receives streaming media via TCP on port 554 and/or via UDP on port2001; for Microsoft Media Streaming (MMS) streaming media, media cache20 receives streaming media data via TCP on port 1755; and for HTTPstreaming media, media cache 20 receives streaming media data via TCP onport 80, or the like. In other embodiments, other ports for thestreaming media may also be used.

The embodiment illustrated above is configured to be accessible fromclient system 10 via a local area network. It should be understood thatstreaming media cache 20 may be alternatively positioned at other pointsin the network, for example, at the edge of a point of presence networkon the Internet, and the like. An example is illustrated in FIG. 1B

FIG. 1B illustrates a overview diagram according to another embodimentof the present invention. In particular, FIG. 1B includes a clientsystem 15, a streaming media cache (server) 25, media data server 35(streaming server), and a router 42. The elements of FIG. 1B are coupledas disclosed over computer networks such as a local area network, widearea networks (Internet), wireless networks or the like. In thisembodiment, streaming media cache 25 may be embodied as an acceleratoron the edge of a point of presence (POP).

In this embodiment, client system 15 initially makes a request for astream of streaming media (representing a streaming media clip). Thisrequest may take the form of a user clicking upon a URL on a web page,or the like. In this embodiment, the request is passed over the widearea network and is intercepted by router 42. Router 42 may be embodiedas a layer 4 or layer 7 switch, a WCCP router, or any other conventionalswitch or router. In this embodiments, router 42 would be configured torecognize when a request is made by client system 10 for a stream ofstreaming media.

If such a request is determined by router 42, that request is redirectedto streaming media cache 25, and not media data server 35. Oncestreaming media cache 25 receives the request, it makes a determinationwhether the streaming media clip or the requested portion of thestreaming media clip has already been cached. If the data has beenpreviously stored, streaming media cache 25 provides the streaming mediato client system 10.

In the present embodiment, if the data has is not stored in streamingmedia cache 25, streaming media cache 25 sends a request to media server35 for the missing data. As the stream of data (including the portion ofthe streaming media clip) is delivered to streaming media cache 25, itis forwarded to client system 15. The missing portion of the streamingmedia clip is then stored in streaming media cache 25. Details of thestorage format and the process of storing and retrieving the stream ofdata are described in greater detail below.

For this embodiment, the streaming media traffic is sent by media cache20 to specific ports. In specific embodiments, for RealSystem streamingmedia, media cache 20 sends streaming media via TCP on port 554; forQuickTime (RTSP) streaming media, media cache 20 sends streaming mediavia TCP on port 554 and/or via UDP on port 2001; for Microsoft MediaStreaming (MMS) streaming media, media cache 20 sends streaming mediadata via TCP on port 1755; and for HTTP streaming media, media cache 20sends streaming media data via TCP on port 80, or the like. In otherembodiments, other ports for the streaming media may also be used.

In other embodiments of the present invention, one or more streamingmedia caches may be positioned simultaneously at the illustratedlocations between client system 15 and media server 35. Additionalstreaming media caches may also be positioned at other locations betweenclient system 15 and media server 35, for example at a user ISP, on anintranet, and the like. In light of this disclosure, it will be apparentthat many other network configurations can incorporate embodiments ofthe present invention.

FIG. 1C illustrates another embodiment of the present invention. In FIG.1C, streaming media caches 26, 27, and 28 store streaming media datathat will be served to client systems. In this embodiment, a contentmanager 29 sends the data to streaming media caches 26, 27, and 28before there is any actual client system requests for the streamingdata. As an example, content manager 29 may use a batch process to pushthe data to media caches 26, 27 and 28 during low traffic times, such as3 am in the morning, or the like.

In the present embodiment, the data that is sent to streaming mediacaches 26, 27 and 28 are typically large file-based transfers. Forexample, the data sent by content manager 29 may be a data file thatstores an entire video or movie. This large data file may be on theorder of tens to hundreds of megabytes, or the like. In embodiments ofthe present invention, the large data file may include data that will beoutput as streaming media in Media Player format (Microsoft), inQuicktime format (Apple), in RealPlayer format (RealNetworks), and thelike.

In one embodiment of the present invention, after a streaming mediacache receives the large data file, the streaming media cache decodes orunpacks the large data file and determines (or computes) and stores the“payload” or media data. More specifically, a streaming media cache thatreceives the large data file, will pre-compute the streaming mediapacket data (payload) and encoding (header) data from the large datafile and store such data in an efficient manner. In the presentembodiment the term “pre-compute” means that the streaming media packetdata is determined from the large data file not in response to an activeclient request, but before any client request. In one embodiment, amethod includes separating the streaming media packet data intorelatively smaller data objects that are separately accessible by thestreaming media cache. Later, when outputting streaming media data,streaming media caches individually access and manipulate the smallerdata objects instead of one large encoded data file.

FIG. 2 is a simplified block diagram of a computer system 45 accordingto an embodiment of the present invention. Computer system 45 may beused as client system 10, streaming media cache 20, and/or media dataserver system 30. Computer system 45 may be a stand-alone computersystem, a computer “appliance,” or the like.

As shown in FIG. 2, computer system 45 includes at least one processor50, which communicates with a number of peripheral devices via a bussubsystem 55. These peripheral devices may include a storage subsystem60, comprising a memory subsystem 65 and a file storage subsystem 70user interface input devices 75, user interface output devices 80, and anetwork interface subsystem 85. The input and output devices allow userinteraction with computer system 45. A user may be a human user, adevice, a process, another computer, and the like.

Network interface subsystem 85 provides an interface to other computersystems. Embodiments of network interface subsystem 85 include anEthernet card, a modem (telephone, satellite, cable, ISDN),(asynchronous) digital subscriber line (DSL) units, and the like.Network interface 250 is coupled to a typical network as shown.

User interface input devices 75 may include a keyboard, pointing devicessuch as a mouse, trackball, touchpad, or graphics tablet, a scanner, abarcode scanner, a touchscreen incorporated into the display, audioinput devices such as voice recognition systems, microphones, and othertypes of input devices. In general, use of the term “input device” isintended to include all possible types of devices and ways to inputinformation using computer system 50.

User interface output devices 80 may include a display subsystem, aprinter, a fax machine, or non-visual displays such as audio outputdevices. The display subsystem may be a cathode ray tube (CRT), aflat-panel device such as a liquid crystal display (LCD), or aprojection device. The display subsystem may also provide non-visualdisplay such as via audio output devices. In general, use of the term“output device” is intended to include all possible types of devices andways to output information from computer system 45.

Storage subsystem 60 may be configured to store the basic programmingand data constructs that provide the functionality of the computersystem and of the present invention. For example, according to anembodiment of the present invention, software modules implementing thefunctionality of the present invention may be stored in storagesubsystem 60. These software modules may be executed by processor(s) 50of computer system 45. In a distributed environment, the softwaremodules may be stored on a plurality of computer systems and executed byprocessors of the plurality of computer systems. Storage subsystem 60may also provide a repository for storing various databases that may beused to store information according to the teachings of the presentinvention. For example, a cache entry hash table, discussed below, maybe stored in storage subsystem 60 of media server 30. Storage subsystemmay also function as a cache of streaming media cache 20. Storagesubsystem 60 may comprise memory subsystem 65 and file storage subsystem70.

Memory subsystem 65 may include a number of memories including a mainrandom access memory (RAM) 90 for storage of instructions and dataduring program execution and a read only memory (ROM) 95 in which fixedinstructions are stored. RAM 90 is typically also used for execution ofprograms, storage of data, and the like.

File storage subsystem 70 provides persistent (non-volatile) storage forprogram and data files, and may include a hard disk drive, a floppy diskdrive along with associated removable media, a Compact Digital Read OnlyMemory (CD-ROM) drive, an optical drive, removable media cartridges, andother like storage media. One or more of the drives may be located atremote locations on other connected computers.

A memory buffer 97 is also provided in storage subsystem 60. In thisembodiment, memory buffer 97 is a special buffer memory coupled to filestorage subsystem 70. More specifically, memory buffer 97 provides atemporary storage area for data retrieved from and data sent to filestorage subsystem 70. Memory buffer 97 may also provide a temporarystorage area for data received from a streaming media server (or otherupstream server) and for data to be sent to client systems. As will bediscussed below, the type of data may include streaming media payloaddata.

In the present embodiment, computer system 45 typically also includessoftware that enables it to send and receive data and communications toand from client systems 10 and media data server 30 using communicationsprotocols including, HTTP, S-HTTP, TCP/IP, UDP, SSL, RTP/RTSP and thelike. In alternative embodiments of the present invention, othersoftware and transfer and communication protocols may also be used, forexample IPX, UDP or the like.

Bus subsystem 55 provides a mechanism for letting the various componentsand subsystems of computer system 45 communicate with each other asintended. The various subsystems and components of computer system 45need not be at the same physical location but may be distributed atvarious locations within a network. Although bus subsystem 55 is shownschematically as a single bus, alternative embodiments of the bussubsystem may utilize multiple busses.

Computer system 45 itself can be of varying types including a personalcomputer, a portable computer, a workstation, a computer terminal, anetwork computer, a mainframe, a kiosk, a personal digital assistant(PDA), a wireless communication device such as a cell phone, anentertainment console (PS2, X-box) or any other data processing system.Due to the ever-changing nature of computers and networks, thedescription of computer system 45 depicted in FIG. 1B is intended onlyas a specific example for purposes of illustrating an embodiment of thecomputer system.

In one embodiment, computer system 45 is embodied as a network cache(appliance) in a product called “NetCache” available fromNetworkAppliance, Incorporated. The NetCache family of productscurrently includes the NetCache C1100, NetCache C3100, and NetCacheC6100 including proprietary, but available hardware and software.Embodiments of the present invention may also be implemented in futureadditions to the NetCache family of products.

It will be readily apparent to one of ordinary skill in the art thatmany other hardware and software configurations are suitable for usewith the present invention. For example, other types of processors arecontemplated, such as the Athlomm class microprocessors from AMD, thePentium™-class or Celeron™-class microprocessors from Intel Corporation,PowerPC™ G3 or G4 microprocessors from Motorola, Inc., Crusoe™processors from Transmeta, Inc. and the like. Further, other types ofoperating systems are contemplated in alternative embodiments includingWindowsNT™ from Microsoft, Solaris from Sun Microsystems, LINUX, UNIX,MAC OS X from Apple Computer Corporation, BeOS™, and the like. Manyother configurations of a computer system are possible having more orfewer components than the computer system depicted in FIG. 1B.

FIG. 3 illustrates a software hierarchy according to embodiments of thepresent invention. In particular, FIG. 3 includes a three-tieredhierarchy including an operating system level (layer) 100, a datahandling level (layer) 110, and a protocol level (layer) 120.

In the present embodiment, as illustrated, operating system level(layer) 100 includes portions of the Berkeley Software Distribution(BSD) operating system. Additionally, operating system level 100includes software provided by the assignee of the present invention:Data ONTAP™, a Network Appliance brand operating system with WriteAnywhere File Layout (WAFL™), a Network Appliance brand file system. Inthe present embodiment, the Data ONTAP™ operating system providesefficient file service by using file-system technology and a microkerneldesign geared towards network data access. The WAFL™ file systemprovides efficient file storage and retrieval based upon efficientaccess algorithms and data structures. Additionally, networkcommunications using Transmission Control Protocol (TCP) and UDP arealso supported at operating system level 100. Of course other types ofoperating systems can also be used.

As illustrated in FIG. 3, data handling level (layer) 110 includes apacket pacing subsystem (SMPACER) 130 and a streaming disk subsystem(SMDISK) 140. In the present embodiment, streaming disk subsystem 140 isused to retrieve data packets from the file system and to provide thedata to SMPACER 130. As will be described below, in one embodiment,SMDISK 140 receives streaming media data packets and in turn SMDISK 140creates a series of specialized data objects for storing the data.Further, SMDISK 140 receives the specialized data objects from the filesystem and stores the data packets into a buffer for output as streamingmedia.

In this embodiment, SMPACER 130 receives data packets (meta-data andpayload data) via a pointer to a buffer location or the like from SMDISK140. In turn, SMPACER 130 sends the pointers to protocol level (layer)120. As described below, protocol level 120 formats the packetsaccording to the desired streaming protocol. The formatted streamingpackets are then received by SMPACER 130. Based upon delivery times foreach packet, SMPACER 130 then sends a stream of packets to the clientsystem at the desired rate. In particular, protocol level 120 “filters”or adjusts the “delivery time” of packets to be output to clients, andthe like. The adjusted meta-data and the payload data are then output bySMPACER 130 to a client, based upon the adjusted delivery time.

In this embodiment, protocol level 120 includes support for at leastone, but typically for more than one streaming media protocols. Thesupport includes encoding of data to form streams of streaming media anddecoding of streams of streaming media. In one example, a streamingmedia protocol is the Microsoft Media Streaming (MMS) protocol. Bysupporting the MMS protocol, streams of MMS formatted data can bereceived from a streaming media (upstream or origin) server and thestreamed (payload) data can be retrieved. This payload data can be sentto data handling layer 110 via SMDISK 140 for storage. Additionally,payload data determined by SMDISK 140 can be encoded into streams of MMSdata. The encoded data are then sent to SMPACER 130 for paced deliveryto a client system. The client system may play the encoded data via aplayer such as Microsoft Windows Media Player, and the like.

In another example, a streaming media protocol is the Real TimeStreaming Protocol (RTSP). In addition to RTSP support, one embodimentincludes Apple QuickTime format support and RealNetworks RealSystemformat support. By supporting these protocols, streams of QuickTimeformatted data or RealSystem data can be received from streaming mediaservers and the respective streaming (payload) data are retrieved. Thesepayloads are then sent to data handling layer 110 via SMDISK 140 forstorage. Additionally, payload data from SMDISK 140 can be encoded intostreams of data and delivered to the client by SMPACER 130. Thestreaming data can be played on client systems via a QuickTime player ora RealSystem player, and the like. In other embodiments, other types ofstreaming media encoding schemes may be supported.

The above hierarchy has been described in embodiments as beingimplemented via software. However, it should be understood that somefunctions may be implemented in hardware or firmware. Accordingly,additional embodiments of the above may be implemented via hardware,firmware, software, and combinations thereof. Further description ofSMPACER 130 will be given below.

FIGS. 4A–D illustrate a data format hierarchy according to an embodimentof the present invention. In particular, FIGS. 4A–D illustrate aninternal storage structure/format used by embodiments for storing datathat will be streamed to client systems.

An example of a streaming media cache implementing a data storagestructure described below is a NetCache™ streaming media cache.NetCache™ (latest version 5.2) includes a combination of hardware andsoftware available from the assignee of the present patent application.Embodiments of the present invention may stream data to client systemsin a variety of streaming media protocols, including Microsoft MediaStreaming (MMS) protocol used by Windows Media Player™; Real TimeStreaming Protocol (RTSP) used by Quicktime™ from Apple Corporation andRealSysteM™ from RealNetworks; and the like.

As illustrated in FIG. 4A, the present embodiment includes a cache entrytable hash table 200 and a plurality of entries wherein each entryincludes an object identifier 210. In one embodiment, object identifiersare file names that have been hashed. Further details regarding thisaspect of the invention are disclosed in the co-pending applicationcited above. Cache entry table 200 typically also includes a pluralityof object handles 220 for a particular object. In the presentembodiment, object handles 220 may be a reference or pointer to anobject 230 corresponding to the object identifier and stored in a cache235.

In the present embodiment, object handles 220 may be used to retrievethe corresponding object 230 from cache 235. According to an embodimentof the present invention, objects 230 are stored as separate data filesin cache 235. In this embodiment, each object handle 220 corresponds toa file handle and the object itself is stored as a file. Accordingly,the individual files are each independently accessible in cache 235 by afile system.

FIG. 4B illustrates a session description 250 (stored in a session datafile or session data object) and logical streams of data 260 and 270according to an embodiment. Logical stream 260 represents data forstreaming media encoded in a first encoding scheme and logical stream270 represents data for streaming media encoded in a second encodingscheme.

In the present embodiment, each of the encodings of the data areconsidered separate streams of data and are stored separately. This isin contrast to cases where multiple encodings of a data stream arepackaged and stored within a single data file. An example of the latteris used by RealNetworks. In particular, a data file used by RealSystemmay include an encoding of data destined for 56 Kbps clients, and anencoding of data destined for 384 Kbps clients. In the presentembodiment, the encoding of data destined for different bit rate clientswould be stored separately. For example, a 56 Kbps encoding would bestored in logical stream 260 and a 384 Kbps encoding would be stored inlogical stream 270. Other typical types of parameters that may be variedfor different encodings may include the bit rate, the content (e.g.abridged, unabridged), the media type (audio and/or video), thinningparameters (frame dropping), and the like.

In FIG. 4B, session description (stored in a session data object orsession data file) 250 may include a description of the various streamsof data stored in logical streams 260 and 270. The description mayinclude an enumeration of the various encoding schemes (e.g. 56 Kbps,128 Kbps, ISDN), copyright and authoring data, presentation or play-time(duration) of the stream, version data, and the like.

As an example, a sample session description for RTSP is as follows. Inparticular, it illustrates extrinsic properties of the media file(author, title, copyright), as well as intrinsic properties of the mediafile (number of media tracks, length of media file, encoding bitrate,MIME type, and codec of each media track, etc.). All of this datatogether serves to help uniquely identify a particular version of theURL used to access the streaming media file.

v=0 o=- 983139433 983139433 IN IP4 172.30.200.154 s=G2 Video Experiencei=RealNetworks ©1998 t=0 0 a=SdpplinVersion:1610642970 a=Flags:integer;2a=IsRealDataType:integer;1 a=StreamCount:integer;2a=Title:buffer;“RzIgVmlkZW8gRXhwZXJpZW5iZQA=”a=Copyright:buffer;“qTE5OTgA” a=Author:buffer;“UmVhbE5ldHdvcmtzAA==” ...a=range:npt=0-0 m=audio 0 RTP/AVP 101 b=AS:6 a=control:streamid=0a=range:npt=0–59.773000 a=length:npt=59.773000 a=rtpmap:101x-pn-realaudio a=mimetype:string;“audio/x-pn-realaudio”a=MinimumSwitchOverlap:integer;200 a=StartTime:integer;0a=AvgBitRate:integer;6000 a=EndOneRuleEndAll:integer;1a=AvgPacketSize:integer;288 a=SeekGreaterOnSwitch:integer;0a=Preroll:integer;4608 a=MaxPacketSize:integer;288a=MaxBitRate:integer;6000 a=RMFF 1.0 Flags:buffer;“AAQAAgAAAAIAAA==” ...a=StreamName:string;“audio/x-pn-multirate-realaudio logical stream” ...m=video 0 RTP/AVP 101 b=AS:50 a=control:streamid=1a=range:npt=0–57.333000 a=length:npt=57.333000 a=rtpmap:101x-pn-realvideo a=mimetype:string;“video/x-pn-realvideo”a=MinimumSwitchOverlap:integer;0 a=StartTime:integer;0a=AvgBitRate:integer;50000 a=EndOneRuleEndAll:integer;1a=AvgPacketSize:integer;538 a=SeekGreaterOnSwitch:integer;1a=Preroll:integer;5707 a=MaxPacketSize:integer;607a=MaxBitRate:integer;50000 a=RMFF 1.0Flags:buffer;“AAoAAgAAAAAAAgACAAAAAgAAAAIAAA==” ...a=StreamName:string;“video/x-pn-multirate-realvideo logical stream” ...

In the present embodiment, logical streams of data, such as logicalstream 260 is made up of a series of data objects 280. As described inFIG. 4A, data objects 280 are physically separate files that aredirectly accessible, independent of other data objects 280, through useof cache entry hash table 200. In this embodiment, data objects 280together store the “media payload” provided by streaming media encodedin a given encoding scheme. For example, the media payload may includethe actual media data included in streaming media packets for a 56 Kbpsstream, or the like. More particularly, data objects 280 store the mediapayload that has been converted from the format in which the originserver stores the media data into the network format for transmission tothe client system and the cache. Accordingly, the data objects includedata that are optimized for delivery to the client system (e.g.,encapsulated in network protocol).

In the present embodiment, each data object 280 is used to store datahaving an associated and/or a predetermined amount of play time(duration). That is, each data object 280 is used to store media payloaddata that will be output as streaming data that will be played on aclient system for a specific amount of time or duration. For example, inone embodiment, each data object 280 is used to store data that will bestreamed to a client as 20 seconds of a music stream, video stream, orthe like. In other embodiments, each data object 280 may store a mediapayload (data) having different duration, such as less than or equal toapproximately 5 seconds, 10 seconds, 20 seconds, 30 seconds, 1 minute,or the like.

In one embodiment of the present invention, the duration of output forthe media payload stored in typical data objects may be fixed for eachdata object among logical streams 260 and 270 (e.g. 15 seconds of astream). However, in other embodiments, the duration of output for themedia payload stored in typical data objects in logical stream 260 anddata objects in logical 270 may be different. For example, for logicalstream 260, the duration may be 15 seconds per data object, and forlogical stream 270, the duration may be 30 seconds per data object, andthe like.

In another embodiment, each data object 280 may store specific amountsof data instead of a specific duration for data. For example, each dataobject 280 may store a predetermined number of bytes of data, forexample, less than or equal to approximately 64 Kbytes, 128 Kbytes, 512Kbytes, 1 Mbyte, or the like. In another embodiment, each data object280 may simply store “chapters” or logical segments of a movie or video,and the like. In one embodiment, each data object 280 stores a fixednumber of data chunks, as described below.

In one embodiment of the present invention, data objects 280 storenon-overlapping data, or unique portions of the media data. That is,each of the data objects 280 may be configured to store a portion of themedia data that is unique to a reference (e.g., URL) in the request tolocations in the origin (or upstream) server at which the media file isstored. In another embodiment, data objects 280 may store media datathat overlaps or is redundant.

FIG. 4C illustrates a detailed description of a data object according toan embodiment of the present invention. As illustrated, FIG. 4C, a dataobject 300 includes object meta-data portion 310, and data chunks 320.

In this embodiment, object meta-data portion 310 is used to store dataabout data object 300. Such meta-data, or header data, may include fileformat version numbers, the number of data chunks 320 stored, thebeginning presentation time and ending presentation time for dataobjects, and the like. In other embodiments, additional data may bestored in object meta-data portion 310 such as the data object number,protocol-specific per-data object data, a total number of bytes ofpayload and meta-data per data object, the number of data packets perdata object, any end of stream indicators, checksum bits and the like.

In one embodiment, each data chunk 320 is also used to store data of apredetermined amount of presentation or play time (duration). That is,each data chunk 320 is used to store streaming data that will be playedon a client system for a specific amount of time. For example, in oneembodiment, each data chunk 320 is used to store 20 seconds of a musicstream. In other embodiments, each data chunk 320 may store havingdifferent duration, such as less than or equal to approximately 5seconds, 10 seconds, 20 seconds, 30 seconds, 1 minute, or the like. Inone embodiment of the present invention, the duration may be fixed foreach data chunk 320 within data object 300. However, in otherembodiments, data objects may have different durations.

In another embodiment, each data chunk 320 may store specific amounts ofdata. For example, each data chunk 320 may store a predetermined numberof bytes of data, for example, less than or equal to approximately 32Kbytes, 64 Kbytes, 128 Kbytes, 512 Kbytes, 1 Mbyte, or the like. In oneembodiment, each data chunk has a fixed number of data packets. In stillother embodiments, data chunks 320 may have a varying number of datapackets.

As will be described below, in the present embodiment, each data chunk320 is used to store the actual streaming media data. More particularly,each data chunk 320 is used to store packets of data that will bestreamed to a client system.

FIG. 4D illustrates a detailed description of a data chunk according toan embodiment of the present invention. Each data chunk 340 includes achunk meta-data portion 350, packet meta-data 360, packet match bits370, and packet payloads 380.

In this embodiment, chunk meta-data portion 350 is used to store dataabout data chunk 340. For example, chunk meta-data portion 350 mayspecify the number of packet payloads (packets) 380, a file offset for aprevious data chunk within the same data object, a file offset for thenext data chunk within the same data object, the number of data packetsin a data chunk, compressed packet meta-data for the packets, describedbelow, and the like. In additional embodiments, the data chunk meta-dataheader may also include packet meta-data for all the data packetsincluding the duration (playback duration) of the payload, thepresentation time of the payload (e.g. time within a movie), thedelivery time of the payload (a time SMPACER 130 delivers the payloaddata to the client), protocol-specific data of the payload, and thelike. Other types of data may be stored in chunk meta-data portion 350in other embodiments, such as timing information, and the like.

Payload packets 380 are used to store streaming data packets that makeup the streaming media. For example, payload packets 380 may store audiodata, image data, audiovisual data, and the like. As will be describedbelow, the streaming data packets may be received as stream of data froma streaming media server, or may be derived from a data file receivedfrom the streaming media server. For Windows Media Player streamingmedia, payload packets 380 range from 200 bytes to 18 Kbytes of data,and for RealSystem streaming media and QuickTime streaming media, packetpayloads 380 range from approximately 200 to 1.5 Kbytes, typically 600bytes. The number of packet payloads in data chunk 340 typically dependsupon the size of packet payloads 380.

In this embodiment, packet meta-data 360 is used to store informationrelevant to or associated with each payload packet 380. Types ofinformation may include the delivery time and the presentation time,file offset of the respective payload packet 380, and the like. In thepresent example, the delivery time is the time SMPACER 130 should sendthe packet payload to the client. In contrast, the packet presentationtime is the time within the media stream that the payload is displayedby the client system.

Packet match bits 370 are used in the present embodiment to storeinformation specific to the streaming media protocol. For example,packet match bits 370 may store data such as flags to identify the startof video key-frames, such as I, B, and or P key frames, or the like. Inthis embodiment, packet match bits 370 are used to determine the firstsendable payload (keyframe) that satisfies a SEEK request by the clientsystem. In one embodiment, the match bits may be embodied as single bit,however, in other embodiments of the present invention, additional matchbits may be used to represent any number of criteria, for example, forselecting which packet will be delivered first, and the like. ForWindows Media Player streaming media, packet match bits 370 may be asmall as a single bit, and for RealSystem streaming media and QuickTimestreaming media, packet match bits 370 are approximately 32 bits.

In this embodiment, the match bits are logically grouped together andseparated from the remaining packet metadata. By grouping of the matchbits together, the match bits can be compressed into, for example, asingle word, thereby saving memory space.

Such key frame data are useful when a client system requests to movearound the stream data, for example, when jumping to a particularpresentation time T within the stream. In this embodiment, based uponpacket match bits 370, the key frame immediately before presentationtime T is retrieved and the play-back is begun from that key frame. Ithas been discovered that in one embodiment, playing-back stream datafrom the immediately-preceding keyframe reduces the amount of mediaartifacts or blank time of the stream when played on the client system.

FIG. 5 illustrates a block diagram of a flow chart according to anembodiment of the present invention. More particularly, FIG. 5illustrates a process of storing streaming media data into embodimentsof the present invention. In the below embodiments, data are typicallystored using the data format hierarchy illustrated in FIGS. 4A–D.

In FIG. 5, a data packet delivered from a streaming media server isreceived in step 400. In one embodiment, the streaming media serverstreams data to the streaming media cache. In such a case, a packet ofdata from the stream includes header data and a data packet (payloaddata). In another embodiment, the streaming media server sends a datafile including the entire data stream to the streaming media cache. Inthis case, data packets and the header data are buried within the datafile.

In the present embodiment, packet meta-data for a particular packet ofdata are then identified, step 410. In one embodiment of the presentinvention, the packet meta-data are derived from the header data of aparticular data packet. In another embodiment, the packet is derivedfrom the data file. The packet meta-data may include a presentation timefor a data packet, an indication of a video key-frame, and the like. Inthis example, presentation time is the time within a media stream wherethe data packet is presented, for example, a data packet may have apresentation time of 20.5 seconds to 20.6 seconds representing when thedata packet is output on the client system.

Next, a determination is made as to whether a new data object should becreated, step 420. A new data object is typically created when a firstdata packet is received, or as described below a previous data object isfull. In one embodiment, a new data object is created, step 430.

Next, a determination is made as to whether a new data chunk within thedata object should be created, step 440. A new data chunk is typicallycreated when a first data packet is received, or as described below, adata chunk is closed after including the previous data packet. In onecase a new data chunk is created, step 450.

The data packet and the packet meta-data are then typically written to abuffer location in the streaming media cache random access memory, step460. This buffer may be RAM 90 or buffer 97. In this embodiment, it isthen determined whether the data packet is the last one for a given datachunk, step 470. If not, the process above is repeated for the next datapacket.

When the data chunk is full, the chunk meta-data are determined, and thedata chunk is written to random access memory (or to disk memory), step480. In this embodiment, it is then determined whether the data chunk isthe last one for a given data object, step 490. If not, the processabove is repeated for the next data packet.

In this embodiment, when the data object is full, the object meta-datadescribed above is determined, and the data object is written to diskmemory, step 400. The process above may then be repeated until there areno more data packets in the media stream.

Accordingly, using the above steps, streaming media data may be receivedby a streaming media cache and stored in a disk memory in theobject-based scheme described above. Additionally, streaming media datamay be received in the form of a data file. This data file is parsed andthe data are also stored in a disk memory in the object-based schemedescribed above.

In the above embodiment, most of the functions are performed by SMDISK140, discussed in FIG. 3. In particular, steps 400 and 470 are typicallyperformed at least in part by SMDISK 140; and step 480 is typicallyperformed by a file system within operating system level 100.

FIG. 6 illustrates a block diagram of a flowchart according to anembodiment of the present invention. In particular, FIG. 6 illustratesan overview of the process of retrieving data stored in a disk memory ofthe streaming media cache as described in FIGS. 4A–D and forming astream of streaming media data to a client system.

In this example, a client system requests streaming media from anembodiment of a streaming media cache, step 500. In one case, a requestfor streaming media may be made directly from a client system or via aproxy. Such a request is typically in the form of a URL, or the like.Additionally, the request may specify a presentation time T thatrepresents the time where the playback should begin. Most requests set Tequal to zero, however T is typically non-zero when the client systemjumps around the media stream (e.g. makes a “seek” request).

If the client system does not terminate its connection with thestreaming media cache, step 510, a determination is made as to whetherto playback the streaming data or not, step 520. In embodiments of thepresent invention, other types of client events may be specified, suchas disconnecting, a play request, a pause request, a stop request, aseek request, notification to the cache that while the client isreceiving streaming data from the cache, that a future object is missingand needs to be prefetched, and the like.

In the present embodiment, if streaming data are to be streamed to theclient system, the presentation time T is determined, step 530. Next,based upon the time T, the payload packet that includes data having thepresentation time T is located, step 540. This step is typicallyperformed in part by SMDISK 140. Next, the data are then formatted forthe specific protocol and then sent to the client system, step 550. Thisstep is typically performed in part by SMPACER 130 and protocol level120. More detailed descriptions of the above steps is given below.

FIG. 7 illustrates a block diagram of a flowchart according to anembodiment of the present invention. In particular, FIG. 7 illustrates amore detailed process of locating and serving data.

In the present embodiment, in response to the presentation time T, thestreaming media cache initially determines which data object to retrievefirst, step 600. In the embodiment above, because an amount of time foreach data object is fixed, for example at 10 seconds, the appropriatedata object can easily be determined. For example, if the presentationtime T were 5 minutes into a data stream, the appropriate data objectwould be the thirtieth one ((5 minutes×60 seconds/minute)/10seconds/data object=30). In one embodiment, the URL of the file, alongwith the presentation time T is first hashed, and the hash is then usedto access the cache entry hash table illustrated in FIG. 4A. In anotherembodiment, a URL of the file, the type of encoding of the file, avalidator for the file, and the time T is hashed, and the hash is usedto access the cache entry hash table illustrated in FIG. 4A. In return,the cache entry hash table provides the appropriate file handle of thetargeted data object.

Based upon the file handle, the object meta-data are first retrieved,step 610. The data are typically stored within RAM 90. Based upon thenumber of chunks of data within the target data object, the target datachunk is determined. In the present embodiment, the meta-data of thefirst data chunk in a data object is first retrieved and stored withinRAM 90. This data also includes the packet meta-data for that datachunk. Then, using the chunk meta-data, by using the file offsetmeta-data, the target data chunk containing the desired packet payload(keyed by presentation time) is determined.

Next, the chunk meta-data of the target data chunk is retrieved, step620. The chunk meta-data are stored within RAM 90 for access byprocessor 50. As described above, the chunk meta-data may specify thenumber of payload packets stored within the chunk. Next, based upon thenumber of payload packets within the data chunk, the target payloadpacket is determined. The packet meta-data of the target payload packetis then retrieved and stored within RAM 90 for access by processor 50,step 630.

In the present embodiment, packet match bits 270 are also retrieved, andif compressed, uncompressed. The packet match bits 270 are typicallystored within RAM 90.

In the present embodiment, portions of the packet meta-data and thetarget payload packet are then combined, step 640. The resulting packetis sent to the client system, step 650. In embodiments of the presentinvention, the target payload packet is the same as what was receivedfrom the origin server. Further, the packet meta-data are typicallyprotocol-specific header data, i.e. the data depends upon the type ofstream provided, such as Quicktime, Windows Media, and the like. forexample, the meta-data may include a per-client sequence number, packettiming information, and the like.

After this target payload packet is sent, this embodiment attempts toiterate to the next payload packet, step 660. If the target payloadpacket is the last one of the target data chunk, step 670, thisembodiment attempts to iterate to the next data chunk. If the targetdata chunk is the last one of the target data object, step 680, thisembodiment attempts to iterate to the next data object. If the targetdata object is the last one of the stream, step 690, the streamterminates.

In the above embodiment steps 600–630 are performed at least in part bySMDISK 140; step 640 is performed at least in part by SMPACER 130; andstep 650 is performed at least in part by SMPACER 130. Morespecifically, SMDISK 140 typically retrieves packet meta-data and packetpayloads from the cache memory (hard disk) and stores them into a memorybuffer, such as buffer 97. SMDISK 140 then gives pointers to thesebuffer locations to SMPACER 130, and in turn SMPACER 130 gives thepointers to these buffer locations to protocol level 120. An encodingprotocol in protocol level 120 processes the meta-data portion, andimportantly, then simply appends the packet payload to form an encodedpacket. This encoded packet is sent to SMPACER 130 for paced delivery toa client.

As illustrated above, packet payloads are simply stored and retrievedfrom the cache memory (hard disk) and no processing occurs on such data.The payload data are merely segmented into convenient-sized data chunksand data objects by SMDISK 140 and then stored in the cache memory. Asdiscussed above, these data objects are individually accessible on afile level.

As described above, in one embodiment, the media server distributes adata file containing all the streaming media streams. For example, thedata file may include encodings for a 56 Kbps data stream, an ISDN datastream, and the like. In other embodiments, a data file may contain aportion of a streaming media stream. In this embodiment, the streamingmedia cache first separates the encoding streams into separate datastructures. Next, for each data structure, the data are converted into alogical stream of data, as illustrated in FIG. 4B. Because the data fileis separated into packets and stored as packets of data, embodiments ofthe present invention are termed to have “pre-computed” the data storedin the payload packets. Later, when a client system desires a particularencoding for a stream of data, the payload packets can simply be outputto the client system. It is believed that this precomputation of thepayload packets, before actually required by a client system, enhancesthe performance of a streaming media cache. Further, by transferring thedata file ahead of time, for example at night time when network trafficis low, instead ofjust when initially requested by a client system, theresponse to a request from a client system is also improved.

Another advantage is that when the streaming media cache is full, itdoes not have to eject or flush an entire data stream, but can simplyeject less frequently requested data objects. For example, the streamingmedia cache can eject the last 10 minutes of an hour long stream, whilemaintaining storage of the first 50 minutes. Thus, in contrast toconventional file level caching, embodiments of the present inventionhave an advantageous level of control over streaming media data. Whenadditional space is required in the cache, seldom accessed portions of adata stream may thus be ejected freeing up space in the media cache fornewer media data, or the like. In other embodiments, other indicia fordetermining when to flush portions of data streams may include uponnumber of requests for data, last request time for the data, based uponpriority for data, and the like.

In view of the above disclosure, many other variations can beenvisioned. For example, the data hierarchy can simply be modifiedaccording to engineering requirements. As an example, the granularitythe data hierarchy can easily be changed and varied based uponexperimental data, and the like. As another example, the sizes of thedata structures may also be varied according to engineeringrequirements.

The invention has been described in embodiments above as a file cache ora streaming media cache. It should be understood, however, that,embodiments may be embodied in any computer system as a stand-alonesystem, or as part of another system. For example, one embodiment may beintegrated into a computer system that includes web server software,database software, and the like. As another example, one embodiment maybe distributed among a set of computer systems in a network, or thelike. In similar examples, when there is a miss, embodiments of thepresent invention may access other embodiments in the network beforeattempting to access an origin server, or the like.

In other embodiments of the present invention, combinations orsub-combinations of the above-disclosed invention can be advantageouslymade. The block diagrams of the architecture and flowcharts are groupedfor ease of understanding. However it should be understood thatcombinations of blocks, additions of new blocks, re-arrangement ofblocks, and the like are contemplated in alternative embodiments of thepresent invention. The specification and drawings are, accordingly, tobe regarded in an illustrative rather than a restrictive sense. It will,however, be evident that various modifications and changes may be madethereunto without departing from the broader spirit and scope of theinvention as set forth in the claims.

1. A method comprising: determining a plurality of payload data packetsfrom a set of data to be streamed to a client system; and storing theplurality of payload data packets in a plurality of data objects in amemory, wherein each data object of the plurality of data objects isdirectly addressable in the memory via an associated object handle, andwherein each data object of the plurality of data objects stores aportion of payload data stored in the payload data packets.
 2. A methodas recited in claim 1, further comprising: determining header data fromthe set of data; and storing a portion of the header data in a sessiondata object in the memory.
 3. A method as recited in claim 2, wherein: adata object of the plurality of data objects comprises an object metadata portion and a plurality of data chunks; and storing the pluralityof payload data packets in the plurality of data objects in the memoryfurther comprises: storing a number representing a total number of datachunks in the plurality of data chunks, in the object meta data portion;and storing a subset of the payload data packets in the plurality ofdata chunks.
 4. A method as recited in claim 3, wherein: a data chunk ofthe plurality of data chunks comprises a chunk meta data portion, packetmeta data portion, and a plurality of packet payloads; and storing asubset portion of payload data from the portion of payload data, furthercomprises: storing a number representing the total number of packetpayloads in the plurality of packet payloads, in the chunk meta dataportion, storing a presentation time for each packet payload, in thepacket meta data portion, and storing a subgroup of payload data fromthe subset portion of payload data, in the plurality of packet payloads.5. A method as recited in claim 4, wherein the plurality of payload datapackets are configured to be played on a media player selected from thegroup comprising: Real Networks Real Player-compatible, Microsoft MediaPlayer-compatible, Apple QuickTime player-compatible.
 6. A method asrecited in claim 4, further comprising streaming plurality of payloaddata packets on a port selected from the group: 554, 2001, 1755,
 80. 7.A method as recited in claim 3, wherein the portion of payload datapackets stored in each of the plurality of data objects is associatedwith a pre-determined amount of presentation time.
 8. A method asrecited in claim 2, wherein determining a plurality of payload datapackets from the set of data comprises pre-computing the plurality ofpayload data packets from the set of data.
 9. A network attachablestorage system comprising: a processor; a network interface coupled tothe processor; and a memory coupled to the processor, the memory storinginstructions which, when executed by the processor, cause the storagesystem to perform a process that includes: receiving a data file thatincludes encoded media data; determining header data from the data file;pre-computing a plurality of payload packets from the encoded mediadata; creating a session data file to store a portion of the headerdata, wherein the header data include an indication of an encodingscheme or a duration, or both; and creating a plurality of data objectsthat store the plurality of payload packets, wherein each data object ofplurality of data objects is directly addressable in the storage systemvia an associated object handle, and wherein each data object of theplurality of data objects stores a set of payload packets from theplurality of payload packets.
 10. A network attachable storage system asrecited in claim 9, wherein: a data object from the plurality of dataobjects comprises an object meta data portion and a plurality of datachunks, the object meta data portion stores a number representing atotal number of data chunks in the data object, and each data chunk ofthe plurality data chunks stores a subset of the set of payload packets.11. A network attachable storage system as recited in claim 9, furthercomprising instructions which, when executed by the processor, cause thestorage system to: retrieve the subset of the set of payload packetsfrom the plurality of data chunks; retrieve the header data from thesession data object; combine the header data and the subset of the setof payload packets to form a stream of media data packets; and serve thestream of media data packets to a client system.
 12. A networkattachable storage system as recited in claim 9, wherein each of thedata objects is associated with a presentation time.
 13. A networkattachable storage system as recited in claim 11, wherein the stream ofmedia data packets is in a format selected from the group: MicrosoftMedia Streaming—compatible, Real Time Streaming Protocol—compatible,RealNetworks—compatible, QuickTime—compatible.
 14. A network attachablestorage system as recited in claim 9, wherein the instructions thatcause the storage system to serve the stream of media data packetscomprise code instructions that cause the storage system to output themedia data packets on a port selected from the group: 554, 2001, 1755,80.
 15. A network attachable storage system as recited in claim 9,wherein the object handle comprises a filename.
 16. An apparatuscomprising: means for determining a plurality of payload data packetsfrom a data file to be streamed to a client system; means fordetermining header data from the data file; means for storing a portionof the header data in a session data object in a cache memory; and meansfor storing the plurality of payload data packets in a plurality of dataobjects in the cache memory, wherein each data object of the pluralityof data objects is directly addressable in the cache memory via anassociated object handle, and wherein each data object of the pluralityof data objects stores a portion of payload data stored in the payloaddata packets.
 17. An apparatus as recited in claim 16, wherein: a dataobject of the plurality of data objects comprises an object meta dataportion and a plurality of data chunks; and the means for storing theplurality of payload data packets in the plurality of data objects inthe cache memory further comprises: means for storing a numberrepresenting a total number of data chunks in the plurality of datachunks, in the object meta data portion; and means for storing a subsetof the payload data packets in the plurality of data chunks.
 18. Anapparatus as recited in claim 17, wherein: a data chunk of the pluralityof data chunks comprises a chunk meta data portion, packet meta dataportion, and a plurality of packet payloads; and the means for storing asubset portion of payload data from the portion of payload data, furthercomprises: means for storing a number representing the total number ofpacket payloads in the plurality of packet payloads, in the chunk metadata portion, means for storing a presentation time for each packetpayload, in the packet meta data portion, and means for storing asubgroup of payload data from the subset portion of payload data, in theplurality of packet payloads.
 19. An apparatus as recited in claim 18,wherein the plurality of payload data packets are configured to beplayed on a media player selected from the group comprising:RealNetworks Real Player-compatible, Microsoft Media Player-compatible,Apple QuickTime player-compatible.
 20. An apparatus as recited in claim18, further comprising means for streaming plurality of payload datapackets on a port selected from the group: 554, 2001, 1755,
 80. 21. Anapparatus as recited in claim 17, wherein the portion of payload datapackets stored in each of the plurality of data objects is associatedwith a pre-determined amount of presentation time.
 22. An apparatus asrecited in claim 16, wherein the means for determining a plurality ofpayload data packets from the data file comprises means forpre-computing the plurality of payload data packets from the data file.